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Box AF 

Commissioner for Patents 

P.O. Box 1450 

Alexandria, VA 22313-1450 

Sir: 

REQUEST FOR RECONSIDERATION AFTER FINAL 

Responsive to the final Official Action dated April 1 , 2008 (for which petition is hereby 
made for a one month extension of time), Applicants respectfully request reconsideration and 
allowance. 

Claims 106-171 stand rejected under 35 U.S.C. §1032 as being unpatentable in view of 
newly-applied Crump. This rejection is respectfully traversed. 

The Examiner states that "[t]he Examiner has full latitude to interpret each claim in the 
broadest reasonable sense." The Examiner is reminded that such interpretations must be 
reasonable when interpreted by one of ordinary skill in the art in light of the specification. See 
MPEP §2111. 
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Cramp addresses the problem of resolving ambiguous local network addresses across 
multiple address domains using a management information base (MIB) that includes 
management objects for configuring and controlling a multi-domain network address translator 
(NAT). The MIB includes objects for defining a domain-specific translation pool, which is a 
range of addresses from which domain-specific translation addresses are selected. As described 
on col. 3, lines 32-36, the NAT maps an overlapping domain-specific address in a first 
(destination) domain (referred to as a local address) to a unique global address that is specific to 
a second (source) domain. Col. 4, lines 13-16 explains that the local address can be mapped to a 
different global address for each destination address domain. For example, in Figure 2, A12 is 
the host X (in domain 1) global address when referenced from domain 2, and Al 3 is the host X 
(in domain 1) global address when referenced from domain 3, and so on. So a local address may 
be mapped to a different unique global address for each address domain. See col. 5, line 64 to 
col. 6, line 5. In the example of Figure 2, different hosts X, Y and Z all have different global 
addresses A12, A13, A14; A21, A23, A24; A31, A32, A34. 

The NAT 102 may create new unique global addresses for its translation tables as part of 
a domain name resolution procedure where a source host having a non-unique local address 
obtains a unique destination global address based upon the domain name of the destination host. 
See Figure 4 where the DNS proxy sends a translation request to the NAT to translate the 
destination host local address, which is not globally unique, into a unique destination host global 
address. In response to the translation request, the NAT determines whether there is already an 
existing translation entry for the destination host local address. If there is, then the NAT simply 
sends a translation response including the destination host global address. If not, then the NAT 
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creates a new entry by selecting a destination host global address from the pool of global 
network addresses to create the needed address translation table entry. 

In contrast, the claimed technology does not make this assumption of limitless supply of 
unique global network addresses. The problem that the claims in this application address and 
solve is that the number of unique global addresses may be limited and not sufficient for a one- 
to-one mapping when a l arge number of local hosts are involved. Crump simply does not 
understand that this is or can be a problem and assumes that there is no limit on the number of 
unique global addresses for use by the NAT 1 02. If a local host-to-unique global address 
mapping is not already provided in the translation table, Crump simply assumes that all that 
needs to be done is to create another translation table entry using a new unique global address. 
The prospect that there may not always be another new unique global address that can be created 
is not even entertained by Crump. 

The Examiner's attention is directed to the following language from independent claim 
106: "prior to initiating establishment of said requested connection . . . determining whether the 
combination of the selected candidate outside-realm gateway address and said multiplexing 
information is already being utilized for another connection." These features are missing in Crump. 

For this step, the Examiner identifies col. 7, lines 46-51, which states: "[u]pon receiving the 
translation request from the DNS Proxy 104, the NAT 102 first determines whether there is an 
existing address translation table entry mapping the destination host local address to a destination 
host global address that is specific to the source address domain." But this is not what is claimed. 
Crump determines if the local destination host address is already translated in the table to a unique 
global destination host address. On the other hand, the claim determines if the combination of a 
global destination host address which may not be unique (i.e., the selected candidate outside-realm 
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gateway address) and multiplexing information is alr eady being used for another connection . This 
text in Crump does not teach combining global destination host address and multiplexing 
information. Nor does it teach checking to see if that combination is already being used for another 
connection. Crump just looks to see if the local to global address translation already exists in the 
NAT table, which is something entirely different. 

The Examiner is requested to identify what in Crump corresponds to the claimed 
combination, pointing out what in Crump corresponds to (1) the claimed selected candidate outside- 
realm gateway address, and (2) the claimed multiplexing information. What in Crump corresponds 
determining whether the combination of (1) and (2) is already being used for another connection ? 

Crump is also missing the next step: 1 ' repeating , if the combination of the selected 
candidate outside-rcalm gateway address and said multiplexing information is already being utilized 
for another connection, the selecting step until a unique combination is found that is not already 
being utilized for another connection ." The checking referred to by the Examiner is merely to see 
if there is already a unique global address assigned to the given/considered local destination host 
in the given destination domain that can be used. But the address domain information in Crump 
is not used as multiplexing infonnation to improve the multiplexing capacity of the gateway. So 
repeating the checking step in Crump referred to by the Examiner will be useless since it will 
always provide the same result — either there is an existing global address assigned to the local 
destination host or there is not. 

Consider the following simple example. Assume that a public host B wants to connect to 
two private nodes Al and A2 and initiates a connection set-up towards node Al, and assume that 
the gateway resource manager finds an available outside gateway address: aOGl . Assume that 
host B also initiates a connection set-up towards node A2, and the gateway resource manager 
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attempts to identify a useful outside gateway address. By using inside node port information in 
the gateway address selection/identification process (for example), the same public gateway 
address, aOGl , may be used for both pending connections towards nodes Al and A2, In other 
words, the two pending connections can be distinguished based on the destination port 
information pAl and pA2. This means that each public gateway address can now be used for 
any number of private nodes, as long as they all listen on different port numbers. (Again, inside 
node port information is only an example of suitable multiplexing information that can be used.) 

The multiplexing gain provided by the claimed technology is not offered by Crump. That 
multiplexing gain provides support for a considerably larger number of simultaneous 
connections compared to the one-for-one address mapping scheme used by Crump. Applicants 
again present the following non-limiting illustration outlined in the previous response to assist in 
understanding this significant benefit. 

A traditional NAT like that in Crump, having 1000 gateway addresses can support 1000 
simultaneous connections. But a NAT having 1000 gateway addresses and information on 1000 
inside port numbers, and/or information on 500 outside node addresses can support up to 1000 x 
1000- 1 000 000 and/or 1000 x 1000 x 500 = 500,000,000 simultaneous connections by using 
the initial address allocation procedure proposed by the claimed technology. In a world in which 
almost all technical devices, such as mobiles and computers but also refrigerators and microwave 
ovens and toasters, are or will be connected to the Internet, there is and continue to be a demand 
for gateways that can support a very large number of simultaneous connections. 

The application is in condition for allowance. An early notice to that effect is requested. 
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